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Abstract  -  The  Software  Hut  (a  small  software  house)  is  a  course 
project  designed  for  a  graduate-level  course  in  computer  program 
engineering.  This  paper  describes  the  Software  Hut  project  and 
discusses  the  authors'  experience  using  it  in  graduate  courses 
at  the  University  of  Toronto.  Suggestions  for  improvements  in 
the  project  are  given. 


The  Computer  Systems  Research  Group  (CSRG)  is  an  interdisciplinary  group 
formed  to  conduct  research  and  development  relevant  to  computer  systems 
and  their  applications.  It  is  jointly  administered  by  the  Department  of 
Electrical  Engineering  and  the  Department  of  Computer  Science  of  the 
University  of  Toronto,  and  is  supported  in  part  by  the  National  Research 
Council  of  Canada. 


Digitized  by  the  Internet  Archive 
in  2018  with  funding  from 
University  of  Toronto 


https://archive.org/details/technicalreportc76univ 


INTRODUCTION 


This  report  describes  one  of  the  most  successful  course  project 
assignments  that  we  have  ever  given.  Its  success  came  neither  from  the 
content  of  the  project  (which  was  quite  ordinary)  nor  from  the  nature  of 
the  course.  Rather,  it  is  attributable  to  the  form  of  the  project,  which 
was  that  of  a  multi-player,  not-quite  zero-sum,  game.  Since  this  form 
could  easily  be  adopted  to  other  courses  in  other  environments,  it  seems 
worth  describing  it  and  discussing  the  factors  that  contributed  to  its 
success. 


THE  ENVIRONMENT 

The  "Software  Hut"  project  was  originally  designed  by  the  first 
author  for  a  graduate  course  in  Computer  Program  Engineering,  fall  term 
1973.  This  course  covers  current  and  proposed  techniques  for  the  produc¬ 
tion  of  computer  programs  that  are  correct,  efficient,  flexible,  main¬ 
tainable,  and  understandable,  in  reasonable  time  spans,  at  acceptable 
costs.  One  major  component  of  the  course  is  a  literature  survey  and 
evaluation,  which  has  resulted  in  four  editions  of  an  annotated 
bibliography  [1,2, 3, 4]. 

The  second  component  is  a  series  of  lectures  and  discussions  of  both 
current  practice  and  future  potentials  in  program  production.  The  third 
is  a  project. 

The  project  was  traditionally  a  source  of  dissatisfaction  within  the 

course.  Ideally  it  should  have  given  students  without  extensive  experience 

\ 

a  glimpse  of  the  problems  faced  by  large  programming  projects  and  given 
those  who  had  such  experience  a  chance  to  measure  their  techniques  against 
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those  of  others;  it  should  have  also  provided  a  laboratory  in  which  both 
groups  could  actually  try  the  techniques  that  they  were  reading  about 
and  discussing.  In  practice,  however,  projects  never  seemed  to  work 
out  that  way.  Simplifications  were  always  needed  to  make  the  project 
fit  within  the  course,  and  projects  were  always  both  "too  big"  and  "too 
small":  too  big,  because  they  took  too  much  time,  and  too  small,  because 
students  felt  that  they  did  not  expose  many  of  the  practical  problems  of 
"real  world"  programming. 


THE  PROJECT  AS  A  GAME 

In  attempting  to  reduce  the  "artificiality"  of  the  project  without 
increasing  its  magnitude,  the  first  author  came  to  the  realization  that 
"real  world"  programmers  (e.g.,  those  employed  by  software  houses)  are 
constantly  working  under  "arbitrary"  (in  the  sense  that  they  have  nothing 
to  do  with  programming)  constraints  imposed  by  their  environment.  Most 
of  these  constraints  are  economic  (in  origin,  if  not  necessarily  in  form), 
and  the  programmer  must  "optimize"  his  performance  in  his  current  environ¬ 
ment.  Thus  the  main  problem  in  project  design  was  that  of  creating  a 
suitable  "economic  environment"  (i.e.,  one  that  reflected  a  sufficient 
number  of  "realistic"  factors  to  be  taken  seriously)  for  the  students. 

As  in  any  serious  game,  it  was  necessary  to  have  a  precise  set  of 
rules,  for  fairness  (this  is  a  major  departure  from  reality),  that  provided 
the  framework  within  which  students  (players)  would  compete,  and  for  those 
rules  to  simulate  interesting  aspects  of  real  situations.  It  was  also 
necessary  to  ensure  that  students  would  find  themselves  playing  the  various 
roles  that  we  wanted  them  to  experience.  It  was  not  necessary  to  duplicate 
any  existing  programming  environment. 


-3- 


Happily,  students  took  the  Software  Hut  project  in  the  spirit  in 
which  it  was  intended.  They  competed  vigourously,  and  learned  a  lot 
about  programming  (and  its  management)  without  any  illusion  that  all 
programming  projects  were  "just  like  this  one."  Furthermore,  they 
seemed  to  enjoy  themselves  in  the  process. 

SOFTWARE  HUT  -  VERSION  1 

The  basic  rules  of  the  original  Software  Hut  are  given  in  Figure  1. 
The  class  consisted  T  students,  making  an  even  6  Huts.  The  particular 
program  to  be  written  (an  Algol  W  paragrapher,  see  Appendix  I),  is  not 
important.  However,  it  did  have  some  important  attributes: 

-  it  was  small,  but  not  trivial  (it  would  probably  have  occupied 
a  single  student  for  about  the  time  allocated  for  the  project); 

-  it  could  be  readily  divided  into  two  major  components,  with  a 
narrow,  easily  specified  interface  between  them; 

-  its  function  could  easily  be  specified  informally  (no  formal 
definition  was  attempted  -  students  were  told  that  real 
specifications  are  typically  imprecise,  incomplete,  ambiguous, 
and  contradictory  -  clarifications  of  intent  were  given  only 
on  explicit  request) ; 

-  a  variety  of  strategies  were  possible  in  the  implementation  of 
either  module; 

-  the  result  was  a  moderately  interesting  program  in  its  own 
right. 

The  division  into  phases  was  done  to  force  students  into  more  roles. 
Not  only  did  each  Hut  have  to  create  (and  presumably  maintain  after  sale) 
its  own  module,  it  also  had  to  interface  modules  written  by  others,  and 
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SOFTWARE  HUT  -  VERSION  1 

Three  persons  comprise  a  Software  Hut.  Huts  are  to  be  formed  by  Day  1. 

Phase  A  (DAYS  1-29) 

Each  Hut  is  to  design,  implement,  validate,  document,  and  otherwise 
prepare  for  sale  either  Module  X  or  Module  Y  of  the  attached  specification 
[Appendix  I]. 


Phase  B  (DAYS  29-50) 

Each  Hut  is  to  write  a  driver  program  and  integrate  Modules  X  and  Y 
purchased  from  two  other  Huts,  and  prepare  the  resulting  system  for  sale. 

Phase  C  (DAYS  50-64) 

Each  Hut  is  to  purchase  a  system  (not  containing  its  own  module)  from 
another  Hut,  modify  it  according  to  revised  specifications  (to  be  provided 
on  Day  53)  [Appendix  III],  and  prepare  the  revised  system  for  sale. 

Scale  Of  Prices 

The  Bank  will  pay  the  following  prices  for  successful  completion  of 
each  phase  by  the  indicated  date: 


i  a  1  i  t  y 

Price 

A+ 

300  Ped 

A 

250  Ped 

A- 

200  Ped 

B+ 

150  Ped 

B 

100  Ped 

B- 

50  Ped 

C 

0  Ped 

(Late  completion  will  be  penalized  25  Ped/day) 

These  prices  will  be  added  to  the  Hut's  trading  profit  (or  loss)  at  the 
end  of  phases  A  and  B  as  indicated  by  sales  recorded  with  the  Bank. 


Figure  1.  The  Basic  Rules 
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later  to  modify  a  system  created  by  others.  Each  Hut  also  found  itself 
worrying  about  both  buying  and  selling,  both  creating  a  salable  product 
and  evaluating  the  product  of  others,  both  requesting  maintenance  and 
providing  it,  etc.  Many  Huts  spent  a  considerable  portion  of  their 
design  effort  on  designing  modules  that  could  easily  cope  with  the 
future  (and  unknown)  modifications. 

Sales  to  the  Bank  served  two  purposes:  they  kept  the  game  from 
being  completely  zero-sum,  and  the  price  scale  provided  a  starting  point 
for  negotiating  prices  between  teams.  Without  them,  the  Ped  (program 
engineering  dollar)  would  have  been  a  completely  meaningless  unit. 

However  the  principal  element  in  each  Hut's  evaluation  was  its  trading 
profit,  which  was  effectively  peer  group  evaluation. 

Four  two-hour  class  periods  (on  Days  1,  29,  50,  and  64)  were  devoted 
to  project  organization  and  discussion.  Days  29  and  50  were  primarily 
devoted  to  competitive  sales  presentations  and  questioning  by  the  various 
teams. 

One  team  proposed  two  changes  to  the  program  specifications  (Appendix 
II).  These  were  distributed  to  the  class,  and  -  in  the  absence  of 
objections  -  adopted  a  week  later. 

The  modifications  distributed  on  Day  53  (Appendix  III)  all  took  the 
form  of  addi tions  to  the  program  specifications  (although  students  had 
not  been  told  that  they  would  have  this  property).  Each  was  something  that 
might  reasonably  have  been  included  in  a  more  complete  program  specification, 
and  was  intended  to  "show  up"  some  implicit  assumption  that  might  have  been 
made  in  program  construction.  They  were  also  designed  to  (probably)  require 
changes  in  both  modules.  The  specific  modifications  requested  were  not 
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particularly  important,  but  it  was  important  that  the  students  did  not  know 
in  advance  what  they  would  be. 

RESULTS  FROM  VERSION  1 

The  enthusiasm  displayed  by  course  members  was,  in  itself,  a  sufficient 
justification  for  this  project.  However,  a  number  of  specific  advantages 
(which  had  not  been  foreseen)  turned  up  during  the  term,  and  seem  to  be 
worth  discussing. 

The  explicitly  "economic"  nature  of  ea ch  H!,+-'c  objective  made  it 
possible  to  conduct  the  project  with  a  minimum  of  'rules  and  specifications. 
It  was  quite  unexpected  to  get  such  good  compliance  with  such  simple  rules. 
For  example,  there  was  no  need  to  specify  the  amount  or  form  of  documenta¬ 
tion;  these  were  tailored  to  encourage  sales  of  the  product.  Similarly, 
testing  was  determined  by  what  was  needed  to  ensure  sales;  questioning 
during  the  sales  periods  tended  to  focus  heavily  on  program  stability 
and  rigour  of  testing.  Huts  worked  out  their  own  contracts  (including 
warranty  and  maintenance  provisions)  based  on  their  own  perceptions  of 
economic  self-interest. 

A  simple  calculation  of  expected  return  quickly  caused  the  Huts  to 
divide  evenly,  three  taking  Module  X  and  three  taking  Module  Y,  and  to 
adopt  a  common  programming  language  (PL/I).  Similarly,  one  of  the  rules 
of  the  game  had  quite  a  fortuitous  "anti -monopoly"  effect.  At  the  end 
of  Phase  A  there  were  a  Module  X  and  a  Module  Y  that  were  clearly  superior 
to  their  competitors.  However,  had  either  Hut  sold  its  module  to  all  five 
of  the  other  Huts,  it  would  have  been  unable  to  meet  the  requirements  of 
Phase  C  ("Each  Hut  is  to  purchase  a  system  (not  containing  its  own  module) 
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from  another  Hut  Had  it  sold  to  four  of  them,  it  would  have  been 

restricted  to  "sole  source"  procurement  from  the  fifth,  and  thereby  sub¬ 
ject  to  extortion.  Each  of  these  Huts,  therefore,  voluntarily  restricted 
its  sales  to  three,  which  left  a  market  for  the  remaining  vendors. 

There  seemed  to  be  quite  a  bit  of  the  desired  role-playing.  The 
fact  that  each  Hut  was  simultaneously  both  buyer  and  seller  apparently 
promoted  more  sel f-conciousness  of  the  conflicts  between  these  roles  than 
would  otherwise  have  occurred. 

The  project  would  have  had  quite  a  different  character  had  the  Huts 
been  individuals,  rather  than  teams  of  three.  Delegation  of  responsibi  1  i ty , 
communication  of  decisions,  coordination  of  activity,  and  resolution  of 
differences  (i.e.,  management  problems)  are  (rightfully)  major  issues  in 
team  projects.  Three  people  seems  to  be  the  right  number;  one  class 
member  put  it  well:  "Three  is  the  smallest  team  that  you  can't  get 
together  on  the  telephone."  Many  of  the  huts  tried  using  organizational 
strategies  discussed  in  class,  e.g.  "egoless"  programming  [5]  and  chief 
programmer  teams  [6]. 

The  requirement  that  Huts  integrate  modules  created  by  two  other 
Huts,  and  modify  a  system  (not  containing  their  own  module)  integrated 
by  another  Hut  also  had  advantages  beyond  the  intended  one  of  learning 
about  maintenance  of  other  people's  code.  Firstly,  at  the  end  of  each 
phase,  the  slate  was  wiped  clean:  no  team  was  stuck  with  the  consequences 
of  its  own  mistakes  in  the  previous  phase  -  even  the  bottom  team  could 
start  afresh  with  something  better.  Secondly,  students  were  able  to 
compare  a  number  of  different  styles  of  programming,  and  rather  directly 
evaluate  their  effect  on  system  integration  and  maintenance. 
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We  cannot  hope  to  list  all  the  lessons  learned  about  computer  program 
engineering  during  the  project.  Doubtless  each  student  picked  up  something 
different.  However,  three  examples  may  be  representative:  1)  One  Hut  used 
52  separate  PUT  statements  throughout  its  Module  Y.  Huts  that  had  to  modify 
this  module  for  multiple-column  output  are  now  vividly  aware  of  the 
desirability  of  collecting  all  output  in  a  single  (small)  routine.  2)  Two 
Huts  voluntarily  limited  themselves  to  the  SP/6  "structured  subset"  of  PL/I 
[7,8].  They  had  much  less  trouble  than  most  other  teams  during  program 
development;  this  was  attributed  partly  to  clear  program  structure,  partly 
to  the  fact  that  no  compiler  problems  were  encountered  using  this  restricted 
subset,  and  partly  to  the  freedom  with  which  they  could  move  from  compiler 
to  compiler  (Checkout,  Optimizer,  F,  PL/C,  PLUTO)  with  consistent  results. 

The  Huts  that  purchased  their  modules  also  agreed  that  they  were  significantly 
easier  to  integrate  and  modify  than  those  that  used  "richer"  subsets  of 
PL/I.  3)  One  student  reported  that  his  team  had  been  so  intent  on  closing 
a  "reciprocal  sale"  arrangement  with  a  customer  at  the  end  of  Phase  B  that 
(to  their  later  sorrow)  they  did  not  carefully  scrutinize  the  product  they 
were  buying. 

FURTHER  EXPERIENCE 

Two  further  Software  Hut  projects  have  been  conducted  in  the  same  course, 
with  somewhat  differing  rules.  The  course  was  taught  again  by  the  first 
author  in  1974,  and  the  rules  were  modified  to  make  them  more  "realistic." 

In  retrospect,  most  of  the  changes  were  mistakes. 

A  major  change  was  to  eliminate  the  static  character  of  Hut  membership. 

At  the  end  of  each  phase,  one  member  of  each  Hut  was  arbitrarily  transferred 
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to  some  other  hut.  This  rapid  turnover  in  personnel,  combined  with  the 
change  in  programs  implied  by  the  sales,  left  students  feeling  that  they 
had  too  little  control  of  the  situation,  and  that  they  were  at  the  mercy 
of  the  "hostile  environment"  (i.e.,  the  instructor).  Thus  the  Huts  never 
developed  the  substantial  team  spirit  of  the  previous  year,  and  were 
noticably  less  enthusiastic  about  the  project. 

The  system  to  be  produced  (a  PL/I  source  text  manipulation  system) 
was  somewhat  larger,  and  -  more  importantly  -  was  divided  into  three 

modules.  The  class  turned  out  to  be  somewhat  smaller  (15  students,  5  huts). 

In  order  to  provide  two  versions  of  each  module,  the  instructor,  the 
teaching  assistant,  and  another  faculty  member  formed  the  sixth  hut.  The 

trading  situation  was  much  more  constrained  with  only  two  sources  for  each 

module.  Although  the  instructor  tried  to  compete  fairly,  there  was  sub¬ 
stantial  uneasiness  (and  some  bitterness)  about  competing  with  a  more 
experienced  hut  that  also  made  and  enforced  the  rules. 

The  price  paid  by  the  Bank  was  calculated  by  a  more  elaborate  formula, 
including  explicit  terms  for  efficiency  (measured  in  terms  of  costs  at 
the  University's  computing  center)  and  for  number  of  errors.  The  latter 
was  particularly  severe:  the  price  was  cut  in  half  for  each  error  discovered 
by  the  Bank.  Also,  in  order  to  encourage  early  consideration  of  later 
phases,  the  Bank's  maximum  prices  were  placed  on  an  escalating  scale: 

Phase  A,  500  Ped;  Phase  B,  1000  Ped;  Phase  C,  1500  Ped.  The  unforseen 
consequence  of  these  rules  was  that  Phase  A  "profits"  were  so  small 
compared  to  time  expended  that  many  students  concluded  that  the  project 
was  not  a  good  way  to  earn  a  grade  in  the  course. 
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Other  changes  that  also  increased  the  "realism"  of  the  project  in 
1974  seem  to  have  uniformly  had  negative  effects.  The  end  result  was 
that  students  stopped  looking  on  the  project  as  a  game,  and  started 
viewing  it  as  a  model  of  reality.  Thus,  unlike  1973,  there  was  a 
reluctance  to  compete  on  the  basis  of  the  given  rules,  and  a  tendency 
to  argue  for  changes  on  the  basis  of  "fairness."  The  greater  complexity 
of  the  rules  made  it  much  harder  to  ensure  that  they  actually  rewarded 
the  behavior  that  the  instructor  was  trying  to  encourage. 

In  1975,  the  second  author  taught  the  course  and  attempted  to  cure 
some  of  the  problems  experienced  in  1974  by  reverting  to  a  simpler  ver¬ 
sion  of  the  project.  There  were  only  two  modules  to  be  built;  X  was  an 
assembler  for  a  simple  (PDP-8  like)  assembly  language,  Y  was  a  loader/ 
interpreter  for  the  simple  machine.  Phase  B  consisted  of  integrating 
purchased  X  and  Y  modules  to  create  a  complete  system.  In  Phase  C  the 
huts  augmented  a  purchased  system  to  add  new  features.  In  this  year 
there  were  again  only  enough  students  to  form  five  huts  so  the  instructor  and 
tutor  formed  a  hut  so  that  there  would  be  three  X  and  three  Y  modules 
available  at  the  end  of  Phase  A.  This  was  still  a  bad  decision.  Cooperation 
with  the  spirit  of  the  game  was  somewhat  dissipated  by  unhappiness  at  having 
this  competition.  The  students  again  chose  PL/I  as  a  common  programming 
language;  unfortunately  the  bit  manipulation  facilities  of  PL/I  are  not 
well-suited  to  the  construction  of  machine  simulators.  The  students  had 
to  spend  an  unreasonable  amount  of  time  fighting  the  language  to  achieve 
the  results  they  wanted. 
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COMMENTS  FOR  INSTRUCTORS 

It  has  been  our  experience  that  a  carefully  designed  project  does 
not  lead  to  an  inordinate  increase  in  the  amount  of  time  required  from 
the  course  instructor.  It  is  important  to  design  the  project  so  that 
the  software  modules  are  of  about  the  same  magnitude  and  have  a 
reasonably  well-defined  interface.  The  modifications  for  Phase  C  should 
be  specified  at  the  same  time  as  the  original  project  so  that  they  are 
not  influenced  by  the  software  actually  produced  and  so  that  there  is 
adequate  time  to  anticipate  possible  difficulties  with  the  modifications. 

To  avoid  conflicts  of  interest  when  the  Bank  has  also  taken  on  the  role 
of  a  hut,  we  have  found  it  desirable  to  ask  some  faculty  member  not 
connected  with  the  course  to  make  up  the  phase  C  specifications,  but  it 
is  even  better  not  to  enter  the  competition  at  all. 

Evaluating  the  modules  at  the  end  of  each  phase  can  be  time-consuming. 

We  have  usually  derived  a  mark  for  each  module  based  on  a  product  of  two 
factors:  one  for  readability  and  comprehensability  and  one  for  time  and 
space  efficiency.  Any  errors  discovered  in  a  module  (e.g.,  any  circumstance 
under  which  the  module  did  something  unexpected  or  unreasonable)  were 
heavily  penalized.  Ideally  the  Bank  should  prepare  a  set  of  rigorous  and 
exhaustive  test  programs  for  each  module  and  conduct  an  acceptance  test 
on  the  module  produced  by  each  hut.  In  practice,  this  is  not  always  possible, 
often  due  to  a  limited  availability  of  instructor  and  tutor  time.  The 
alternative,  attempting  to  quantify  program  correctness  and  efficiency  from 
an  inspection  of  the  source  program  has  proved  to  be  only  moderately 
satisfactory. 

So  far  we  have  been  fortunate  that  the  self-interest  of  continuing 
with  the  project  has  been  a  strong  enough  glue  to  keep  even  contentious 
huts  together  for  the  duration  of  the  project.  A  hut  that  decides  to 
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dissolve  part  way  through  the  project  poses  a  number  of  administrative 
problems  (and  adds  some  realism  at  the  same  time).  At  this  point  the 
instructor  has  to  reassign  the  students  to  other  huts  and  come  up  with 
some  fair  way  of  apportioning  marks. 

AREAS  FOR  CHANGE 

No  project  is  ever  perfect,  and  the  Software  Hut  is  no  exception. 

Students  have  pointed  out  many  possible  changes  in  the  project  format. 

It  has  been  our  experience  that  as  we  increase  the  realism  of  the  project 
we  also  tend  to  increase  the  amount  of  strife  ^ano  student  discontent. 

(Perhaps  this  is  a  comment  on  the  typical  student  attribute  toward  the 
real  world.)  We  discuss  below  some  thoughts  on  adding  to  the  realism  of  the 
course  and  also  discuss  some  issues  that  seem  to  be  chronic  problems. 

It  is  unrealistic  to  have  three  or  six  Huts  all  doing  the  same  thing. 

In  actual  fact,  customers  almost  never  have  the  luxury  of  choosing  between 
even  two  programs  written  to  the  same  specification.  An  alternative  to 
the  present  project  would  be  to  take  some  large  existing  program  (e.g., 
a  compiler)  and  assign  the  huts  to  make  modifications  to  specific  program 
functions . 

It  would  be  desirable  to  account  for  the  resources  (man-hours, 
machine  time)  consumed  by  each  hut  and  to  deduct  the  "cost"  of  these  resources 
from  the  profit  of  each  hut.  This  has  not  been  possible  at  our  University 
due  to  the  availability  of  "free"  (unaccounted)  computing  for  small  jobs. 

In  the  past  we  have  allowed  the  class  to  select  the  common  programming 
language  for  the  project;  the  choice  has  always  been  PL/I.  In  the  first 
two  years,  this  was  an  advantage:  PL/I  was  reasonably  suitable  for  the 
programming  involved,  and  its  large  size  catered  to  a  variety  of  good  and 
bad  programming  styles,  which  students  could  then  compare. 
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In  the  most  recent  project,  PL/I  turned  out  to  be  an  unfortunate  choice, 
since  the  assembler/simulator  required  the  students  to  become  intimately 
familiar  with  some  really  unpalatable  parts  of  PL/I.  Most  of  the  students 
actually  had  to  learn  PL/I  for  the  project  and  spent  a  lot  of  effort  doing 
so.  We  now  feel  that  the  students  lack  sufficient  knowledge  of  what  the 
project  will  entail  and  hence  can't  make  a  rational  decision  on  a  good 
programming  language.  The  Bank  should  choose  the  common  programming 
language  appropriate  for  the  project. 

There  has  always  been  a  lot  of  student  unrest  about  the  process  of 
buying  and  selling  software."  They  point  out  that  we  do  not  teach  software 
marketing  and  they  are  totally  unprepared  for  the  negotiations  that  take 
place.  Many  students  feel  that  it  is  unfair  to  require  them  to  try  to  get 
a  good  grade  at  the  expense  of  their  classmates.  We  now  think  that  the 
emphasis  on  interactive  buying  and  selling  should  be  reduced.  One 
alternative  would  be  for  the  Bank  to  fix  the  price  of  each  module  based 
on  its  own  evaluation  and  give  the  huts  a  choice  of  taking  any  module 
(except  their  own)  at  the  bank's  price.  This  change  would  eliminate  the 
contentious  price  bargaining  that  now  occurs.  If  the  same  project  is 
repeated,  modules  produced  in  previous  years  could  also  be  made  available 
by  the  Bank.  (However,  it  would  be  unwise  to  repeat  the  modifications 
from  previous  years.) 


CONCLUSIONS 

Most  people  enjoy  competitive  games.  Properly  designed,  serious  games 
can  also  provide  an  educational  experience  that  is  difficult  to  match. 

The  incorporation  of  explicit  "economic"  factors  into  course  programming 
projects  seems  to  be  worthwhile.  The  rules  of  Software  Hut  have  worked 


well  in  our  Computer  Program  Engineering  course,  as  long  as  they  were 
simple.  Similar  games  with  somewhat  different  objectives  could  be  devised 
for  other  courses. 
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Appendix  I 

Program  Specifications 

(Distributed  Day  -3) 

General  description:  The  end  product  is  to  be  a  complete  paragrapher  for 
Algol  W  programs,  constructed  of  two  major  modules  (X  and  Y)  and  a  driver 
program.  -The  paragraphing  strategy  (suggested  by  Jean  Ichbiah)  is  to 
identify  the  nesting  structure  of  the  program,  and  within  a  level  of 
nesting,  a  set  of  acceptable  division  points;  if  a  nested  unit  can  be 
placed  on  a  single  line  (properly  indented,  of  course),  it  should  be, 
otherwise  it  should  be  split  into  lines  at  all  division  points  (at  that 
level),  the  level  of  indentation  increased  one  tab,  and  the  strategy 
applied  recursively  to  the  component  groups. 

The  driver  program  will  take  the  general  form  of  a  loop  that  alternately 
calls  X  to  get  a  token  and  Y  to  dispose  of  it,  until  X  signals  that  the 
input  is  exhausted.  It  may  declare  (separately)  variables  needed  as  globals 
by  X  and  Y,  but  they  are  not  allowed  to  have  any  globals  in  common,  nor 
to  communicate  other  than  by  the  token  stream.  The  driver  may  call  X 
and  Y  with  special  parameters  to  trigger  initialization,  but  it  is  not 
to  execute  initialization  code  for  these  modules  directly. 

Module  X  is  responsible  for  input  and  scanning  of  the  source  program, 
its  analysis,  and  the  production  of  the  token  stream.  It  is  allowed  a 
small  amount  of  buffer  store,  which  should  not  depend  on  the  size  of  the 
program  being  paragraphed.  The  quality  of  paragraphing  will  depend 
strongly  on  the  judicious  identification  of  nesting  structure  and 
division  points,  so  the  method  selected  for  this  function  is  of  major 
concern.  While  syntactic  errors  in  the  source  program  that  will  upset  the 
paragraphing  (e.g.,  unbalanced  begin-end  structure)  should  be  appropriately 
diagnosed,  the  quality  of  error  recovery  is  of  secondary  importance. 
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Module  Y  is  responsible  for  output  of  the  properly  paragraphed 
program.  It  should  be  flexible  with  regard  to  number  of  characters  per 
line,  lines  per  page,  tab  size,  etc.  It  is  allowed  a  small  amount  of 
buffer  store,  which  should  not  depend  on  the  size  of  the  program  being 
paragraphed.  Exceptional  conditions  (e.g.,  strings  longer  than  one  line, 
indentation  "deeper"  than  line  length)  must  be  handled  reasonably. 

Invalid  token  strings  should  generate  warning  messages,  but  otherwise  have 
minimal  ill  effects. 

Interface  specification:  Tokens  shall  be  coded  with  the  following  numerical 
values : 

0  e  (error) 

1  b_  (significant  blank) 

2  [  (open  bracket) 

3  ]  (close  bracket) 

4  a  (division  point) 

5  (terminal  symbol) 

6  eo£  (end  of  input) 

Terminal  symbols  shall  be  passed  with  code  5  plus  an  EBCDIC  character 
stri  ng . 

The  token  stream  shall  conform  to  the  following  BN F  grammar: 

<stream>  ::=  [  <Unit>  ] 

<Unit>  : :=  <Group> 

|  <Unit>  A  <Group> 

<Group>  ::=  <Element> 

|  <Group>  <Element> 

<Element>  : :=  <Terminal> 

|  <Stream> 

I  b 

An  example  of  input  and  output  is  given  in  Figure  2. 
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Sample  Input: 

begin  n nteger  X ,  Y ,  Z ; 
real  I ,  J ; 

X :=5 ;  Y :=3;  I:=X+Y; 
if  X  >  I  then 
begin 
J  :=Z; 

X :  =  I 
end 

else  I :=J 

end. 

Samp! e  Token  stream: 

[begin  [[  integer  b  X,  A  Y,  A  Z;  ]  [  real  b  I,  A  J  ;  ] 

[X  b  :=  A  5;  ]  [Y  b  :=  A  3;  ]  [I  b  :=  [Xb^+AY;]  ]  [  if  [  X  b_  >  A  I  ]  then  A 

begi n  [[  J  b  :=  [[  J  b  :=  A  Z;  ]  ]  X  b  :=  A  I  ]]  end  A  el se  ]Ib_:=AJ]]]  end  . ] 

Sample  output  (line  =  40  characters,  tab  =  4  spaces): 

•  •  •  •  •  •  •  • 

begin 

i nteger  X ,  Y ,  Z ; 
real  I ,  J ; 

X  :=  5; 

Y  :=  3; 

I  :=  X  +  Y; 

if  X  >  I  then 

begin  J  :=  Z;  X  :=  I  end 
else  I  :=  J 

end . 


Figure  2.  An  Example 
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Appendix  II 

Changes  to  Specifications 


PROPOSAL  I 


The  BNF  grammar  for  the  token  stream  should  be  changed  to  the 
following: 


<STREAM> 

[<UNIT>] 

<UNIT> 

::=  <GR0UP> 

|  <UNIT>  A  <GR0UP> 

<GR0UP> 

::=  <-3TR£AM> 

|  <ELEMENT-LIST> 

<ELEMENT-LIST> 

::=  <ELEMENT> 

|  <ELEMENT-LIST>  <ELEMENT> 

<ELEMENT> 

::=  <TERMINAL> 

This  change  will  require  that  module  X  explicitly  mark  all  division 
points  with  A  Vs.  (Module  Y  need  make  no  assumptions  about  division 
points  implied  by  brackets.)  Every  bracketed  unit  will  be  permitted  to 
appear  by  itself  on  a  single  line,  if  this  is  possible  in  the  available 
line  size. 

The  change  is  necessary  in  order  to  guarantee  that  a  unit  (as 
defined  in  the  specification  and  the  BNF)  may  always  be  broken  into 
constituent  groups.  As  it  stands,  a  unit  may  be  composed  from  a  single 
group  formed  from  successive  elements  with  no  division  points. 
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PROPOSAL  2 

The  functional  specification  should  be  modified  so  that  its  second 
part  reads  as  follows: 

"If  a  nested  unit  can  be  placed  on  a  single  line  (properly 
indented,  of  course),  it  should  be.  Otherwise  it  should 
be  split  into  groups  at  all  division  points  (at  that  level), 
the  strategy  should  be  applied  recursively  to  the  first 
group,  the  level  of  indentation  should  be  increased  one 
tab,  and  the  strategy  should  be  applied  recursively  to 
the  remaining  groups  in  succession." 

This  specification  has  the  following  effects: 

1)  The  first  token  after  each  division  point  at  any  level  will 

begin  in  the  same  column  (eliminating  the  possibility  that 
the  keywords  INTEGER  and  REAL  in  the  example  will  start  in 
different  columns  and  preventing  the  occurrence  of  two  or 
more  tab  increments  with  no  text  appearing  at  the  intervening 
levels ) . 

All  continuation  lines  of  a  unit  will  be  indented  beyond  the 
first  line.  (This  includes  the  END  in  a  BEGIN-END  block). 


2) 
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Appendix  III 

Additions  to  Program  Specifications 

(Distributed  Day  53) 

In  addition  to  the  requirements  previously  stated,  your  Algol  W 
paragrapher  is  to  have  all  the  following  properties: 

1.  Card  Output:  If  the  output  of  the  paragrapher  is  directed  to  a 


card  punch,  the  resulting  deck  must  contain  a  paragraphed  program 
which  is  in  suitable  form  for  input  to  the  Algol  W  compiler 
(and,  of  course,  the  paragrapher  iisplfl 


2.  Idempotence:  If  P(S)  denotes  the  result  of  paragraphing  the  source 

program,  then  P (P (S) )  =  P(S)  must  hold  for  all  valid  S. 

3.  Formatted  comments:  Any  comment  whose  first  non-blank  character  is 


is  to  be  reproduced  exactly  as  it  appears  in  the  source  pro¬ 
gram  (if  the  line  length  is  long  enough  -  otherwise  it  may  be 
split  over  multiple  lines)  i.e.,  blanks  are  significant  and 
indentation  is  suppressed.  All  other  comments  are  to  be  suitably 
indented  and  paragraphed  "reasonably." 


4.  Multiple  columns:  If  the  specified  line  length  is  N^65  characters, 


print  the  paragraphed  listing  in  |J32/(N  +  1  )\  columns  across 
the  page,  e.g. , 


BEGIN 


BEGIN 


REAL  S; 


S  :  =  1/1  +  S; 
WRITE  (S) 

END; 

WRITE  ('SUM  =  1 ,S) 


COMMENT  PARTIAL  SUM  ; 


S  :  =  1; 


WRITE  (S); 


FOR  I  :=  2  STEP  1 


END 


UNTIL  100  DO 
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